-
Notifications
You must be signed in to change notification settings - Fork 139
internal/oauthex: OAuth extensions #125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey guys, I'm tasked with moving a production MCP server from Python to Go, and just started looking at this repo, so forgive me if I'm missing something. But based on this PR, I see that you:
- Mount discovery endpoints (/.well-known/oauth-protected-resource)
- Handle 401 responses with WWW-Authenticate headers
- Provide OAuth server discovery
- Use token binding to specific resources
This is obviously valuable since it is needed to protect the routes. And in my case (as in what I asume most people's case, the oauth server provides a vast majority of the inputs for this). But instead of 2.0, don't we need OAuth 2.1 (I have a feeling we kind of get this for free because this is just a discovery endpoint and the clinet will have to do PKCE with the end server), but I want to be clear that our testing revolves around 2.1 while also thinking about how an sdk end user will actually configure the ResourceMetadata. Like is it:
server := mcp.NewServer(impl, caps)
// Configure resource metadata (RFC 9728)
server.SetResourceMetadata(&oauthex.ProtectedResourceMetadata
{
ResourceServers: []oauthex.ResourceServer{
{
Resource: "https://myapp.com/mcp",
AuthorizationServers:
[]string{"https://myapp.com/oauth"},
ScopesSupported: []string{"user:read",
"user:write", "mcp:access"},
// OAuth 2.1 specific requirements
PKCERequired: true,
TokenEndpointAuthMethodsSupported:
[]string{"client_secret_basic", "private_key_jwt"},
},
},
})
Also i know this Pr is specifically for just defining the metadataserver, but is there a but is there a plan for how the data configured here will be used on the MCP tool calling side to make the token accessible by the tool without needing to pull in custom HTTP headers?
For example, would we eventually be able to do something like:
server.RegisterTool(&mcp.ToolDefinition{
Name: "search_users",
RequiredScopes: []string{"user:read"}, // Links to
ResourceMetadata.ScopesSupported
Handler: func(ctx context.Context, session
*mcp.ServerSession, params *mcp.CallToolParams)
(*mcp.CallToolResult, error) {
// Token and user context automatically available
from OAuth flow
user := session.GetAuthenticatedUser()
// ... business logic
},
})
```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RoyceLeonD Can you file an issue for making the token attributes accessible to the server-side feature (tool, prompt, etc.)? Besides the user, what else is valuable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RoyceLeonD I'd like you to take a look at #176 and tell me your thoughts.
Add a package for the extensions to OAuth 2.0 required by MCP. This first PR adds Protected Resource Metadata.
Add a package for the extensions to OAuth 2.0 required by MCP.
This first PR adds Protected Resource Metadata.